Tox testēšanas automatizācija: padziļināta analīze par vairāku vides testēšanu globālām komandām

Mūsdienu globālajā programmatūras vidē frāze "tas darbojas manā datorā" ir vairāk nekā tikai izstrādātāju klišķis; tā ir ievērojams uzņēmējdarbības risks. Jūsu lietotāji, klienti un sadarbības partneri ir izkaisīti pa visu pasauli, izmantojot dažādas operētājsistēmas, Python versijas un atkarību kopas. Kā jūs varat nodrošināt, ka jūsu kods ir ne tikai funkcionāls, bet arī uzticami stabils visiem un visur?

Atbilde ir sistemātiska, automatizēta testēšana vairākās vidēs. Šeit Tox, rīks, ko vada komandrinda, kļūst par neaizstājamu mūsdienu Python izstrādātāja rīkkopa. Tas standartizē testēšanu, ļaujot jums definēt un izpildīt testus dažādās konfigurāciju matricās ar vienu komandu.

Šis visaptverošais ceļvedis jūs iepazīstinās ar Tox pamatiem un uzlabotām stratēģijām testēšanai vairākās vidēs. Mēs izpētīsim, kā izveidot noturīgu testēšanas cauruļvadu, kas nodrošina jūsu programmatūras saderību, stabilitāti un gatavību globālai auditorijai.

Kas ir testēšana vairākās vidēs un kāpēc tā ir kritiska?

Testēšana vairākās vidēs ir jūsu testu kopas izpildes prakse vairākās, atšķirīgās konfigurācijās. Šīs konfigurācijas jeb "vides" parasti atšķiras pēc:

• Python interpretatora versijas: Vai jūsu kods darbojas Python 3.8 tāpat kā Python 3.11? Ko darīt ar nākamo Python 3.12?
• Atkarību versijas: Jūsu lietojumprogramma varētu būt atkarīga no bibliotēkām, piemēram, Django, Pandas vai Requests. Vai tā sabojāsies, ja lietotājam būs nedaudz vecāka vai jaunāka versija šīm pakotnēm?
• Operētājsistēmas: Vai jūsu kods pareizi apstrādā failu ceļus un sistēmas izsaukumus operētājsistēmā Windows, macOS un Linux?
• Arhitektūras: Ar ARM bāzes procesoru (piemēram, Apple Silicon) izplatību testēšana uz dažādām CPU arhitektūrām (x86_64, arm64) kļūst arvien svarīgāka.

Biznesa pamatojums vairāku vides stratēģijai

Laika investīcija šāda veida testēšanas izveidē nav tikai akadēmisks vingrinājums; tam ir tiešas biznesa sekas:

• Samazina atbalsta izmaksas: Agrīni uztverot savietojamības problēmas, jūs novēršat atbalsta biļešu plūdus no lietotājiem, kuru vides jūs nebūtu paredzējuši.
• Palielina lietotāju uzticību: Programmatūra, kas uzticami darbojas dažādās konfigurācijās, tiek uztverta kā augstākas kvalitātes. Tas ir svarīgi gan atvērtā pirmkoda bibliotēkām, gan komerciāliem produktiem.
• Nodrošina vienmērīgākus jauninājumus: Kad tiek izlaista jauna Python versija, jūs vienkārši varat to pievienot savai testu matricai. Ja testi iziet, jūs zināt, ka esat gatavs to atbalstīt. Ja tie neizdodas, jums ir skaidrs, uzrādāms to, kas jālabo.
• Atbalsta globālās komandas: Tas nodrošina, ka izstrādātājs vienā valstī, kas izmanto jaunākos rīkus, var efektīvi sadarboties ar komandu citā reģionā, kas varētu būt uz standartizēta, nedaudz vecāka uzņēmuma krājuma.

Iepazīšanās ar Tox: Jūsu automatizācijas komandcentrs

Tox ir izstrādāts, lai eleganti atrisinātu šo problēmu. Pamatā Tox automatizē izolētu Python virtuālo vides izveidi, instalē jūsu projektu un tā atkarības tajās un pēc tam izpilda jūsu definētās komandas (piemēram, testus, lintētājus vai dokumentācijas būvēšanu).

Tas viss tiek kontrolēts ar vienu vienkāršu konfigurācijas failu: tox.ini.

Sākšana: instalēšana un pamata konfigurācija

Instalēšana ir vienkārša ar pip:

pip install tox

Tālāk izveidojiet tox.ini failu sava projekta saknē. Sāksim ar minimālu konfigurāciju testēšanai vairākās Python versijās.

Piemērs: Pamata tox.ini

[tox]
min_version = 3.7
isolated_build = true
envlist = py38, py39, py310, py311

[testenv]
description = Run the main test suite
deps = pytest
commands = pytest

Sadaliet to:

• [tox] sadaļa: Šī ir globāliem Tox iestatījumiem.
• min_version: Norāda minimālo Tox versiju, kas nepieciešama šīs konfigurācijas izpildei.
• isolated_build: Mūsdienu labākā prakse (PEP 517), kas nodrošina, ka jūsu pakete tiek izveidota izolētā vidē pirms instalēšanas testēšanai.
• envlist: Šī ir testēšanas vairākās vidēs sirds. Tā ir ar komatu atdalīts saraksts ar vidēm, kuras Tox ir jāpārvalda. Šeit mēs definējām četras: pa vienai katrai Python versijai no 3.8 līdz 3.11.
• [testenv] sadaļa: Šis ir paraugs visām vidēm, kas definētas envlist.
• description: Noderīgs ziņojums, kas izskaidro, ko vide dara.
• deps: Atkarību saraksts, kas nepieciešams jūsu komandu izpildei. Šeit mums vajadzīgs tikai pytest.
• commands: Komandas, kas jāizpilda virtuālajā vidē. Šeit mēs vienkārši izpildām pytest testu palaidēju.

Lai to izpildītu, pārejiet uz sava projekta saknes direktoriju savā terminālā un vienkārši ierakstiet:

tox

Tox tagad veiks šādas darbības katrai videi envlist (py38, py39 utt.):

1. Meklējiet atbilstošo Python interpretatoru savā sistēmā (piemēram, `python3.8`, `python3.9`).
2. Izveidojiet jaunu, izolētu virtuālo vidi direktorijā .tox/.
3. Instalējiet savu projektu un atkarības, kas uzskaitītas zem `deps`.
4. Izpildiet komandas, kas uzskaitītas zem `commands`.

Ja kāds solis neizdodas kādā vidē, Tox ziņos par kļūdu un iziet ar nenulles statusa kodu, padarot to ideāli piemērotu nepārtrauktas integrācijas (CI) sistēmām.

Padziļināta analīze: jaudīgas tox.ini izveide

Pamata iestatījums ir jaudīgs, taču patiesais Tox burvība slēpjas tā elastīgajās konfigurācijas iespējās sarežģītu testu matricu izveidošanai.

Ģenerējošās vides: kombinatoriskās testēšanas atslēga

Iedomājieties, ka jums ir bibliotēka, kurai jāatbalsta Django versijas 3.2 un 4.2, kas darbojas Python 3.9 un 3.10. Manuāli definēt visas četras kombinācijas būtu atkārtoti:

Atkārtotais veids: envlist = py39-django32, py39-django42, py310-django32, py310-django42

Tox nodrošina daudz tīrāku, ģenerējošu sintaksi, izmantojot figūriekavas {}:

Ģenerējošais veids: envlist = {py39,py310}-django{32,42}

Šī viena rinda tiek paplašināta līdz tām pašām četrām vidēm. Šī pieeja ir ļoti mērogojama. Jaunas Python versijas vai Django versijas pievienošana ir tikai viena vienuma pievienošana attiecīgajam sarakstam.

Faktora nosacītās iestatījumi: katras vides pielāgošana

Tagad, kad esam definējuši savu matricu, kā mēs sakām Tox, lai instalētu pareizo Django versiju katrā vidē? Tas tiek darīts ar faktora nosacītajiem iestatījumiem.

[tox]
envlist = {py39,py310}-django{32,42}

[testenv]
deps =
    pytest
    django32: Django>=3.2,<3.3
    django42: Django>=4.2,<4.3
commands = pytest

Šeit rinda `django32: Django>=3.2,<3.3` saka Tox: "Iekļaujiet šo atkarību tikai tad, ja vides nosaukums satur faktoru `django32`." Tāpat arī `django42`. Tox ir pietiekami gudrs, lai parsētu vides nosaukumus (piemēram, `py310-django42`) un lietotu pareizos iestatījumus.

Šī ir neticami jaudīga funkcija, lai pārvaldītu:

• Atkarības, kas nav saderīgas ar vecākām/jaunākām Python versijām.
• Testēšana pret dažādām galveno bibliotēku versijām (Pandas, NumPy, SQLAlchemy utt.).
• Platformai specifisku atkarību nosacītā instalēšana.

Projekta struktūra, pārsniedzot pamata testus

Izturīgs kvalitātes cauruļvads ietver vairāk nekā tikai testu izpildi. Jums arī jāizpilda lintētāji, tipu pārbaudītāji un dokumentācijas būvēšana. Ir laba prakse šiem uzdevumiem definēt atsevišķas Tox vides.

[tox]
envlist = py{39,310}, lint, typing, docs

[testenv]
deps = pytest
commands = pytest

[testenv:lint]
description = Run linters (ruff, black)
basepython = python3.10
deps =
    ruff
    black
commands =
    ruff check .
    black --check .

[testenv:typing]
description = Run static type checker (mypy)
basepython = python3.10
deps =
    mypy
    # also include other dependencies with type hints
    django
    djangorestframework
commands = mypy my_project/

[testenv:docs]
description = Build the documentation
basepython = python3.10
deps = sphinx
commands = sphinx-build -b html docs/source docs/build/html

Šeit ir tas, kas ir jauns:

• Konkrētas vides sadaļas: Mēs pievienojām `[testenv:lint]`, `[testenv:typing]` un `[testenv:docs]`. Šīs sadaļas definē iestatījumus konkrēti šīm nosauktajām vidēm, pārrakstot noklusējuma vērtības sadaļā `[testenv]`.
• basepython: Ne-testa vidēm, piemēram, `lint` vai `docs`, mums bieži vien nav nepieciešams tos izpildīt uz katras Python versijas. `basepython` ļauj mums piespraust tos pie noteikta interpretatora, padarot tos ātrākus un deterministiskākus.
• Skaidra atdalīšana: Šī struktūra uztur jūsu atkarības tīras. `lint` vide instalē tikai lintētājus; jūsu galvenajām testēšanas vidēm tie nav nepieciešami.

Tagad jūs varat izpildīt visas vides ar `tox`, noteiktu kopu ar `tox -e py310,lint` vai tikai vienu ar `tox -e docs`.

Tox integrācija ar CI/CD globālai automatizācijai

Tox izpildīšana lokāli ir lieliska, taču tās patiesais spēks tiek atklāts, kad tā tiek integrēta nepārtrauktas integrācijas/nepārtrauktas izvietošanas (CI/CD) cauruļvadā. Tas nodrošina, ka katras koda izmaiņas tiek automātiski validētas pret jūsu pilnu testu matricu.

Pakalpojumi, piemēram, GitHub Actions, GitLab CI un Jenkins, ir lieliski piemēroti šim nolūkam. Tie var izpildīt jūsu uzdevumus uz dažādām operētājsistēmām, ļaujot jums izveidot visaptverošu OS savietojamības matricu.

Piemērs: GitHub Actions darba plūsma

Izveidosim GitHub Actions darba plūsmu, kas paralēli palaidīs mūsu Tox vides Linux, macOS un Windows vidē.

Izveidojiet failu vietnē .github/workflows/ci.yml:

name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        python-version: ['3.8', '3.9', '3.10', '3.11']

    steps:
    - name: Check out repository
      uses: actions/checkout@v3

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}

    - name: Install Tox
      run: pip install tox tox-gh-actions

    - name: Run Tox
      run: tox -e py

Analizēsim šo darba plūsmu:

• strategy.matrix: Šī ir mūsu CI matricas pamatā. GitHub Actions izveidos atsevišķu uzdevumu katrai `os` un `python-version` kombinācijai. Šai konfigurācijai tas ir 3 operētājsistēmas × 4 Python versijas = 12 paralēli uzdevumi.
• actions/setup-python@v4: Šī standarta darbība iestata konkrēto Python versiju, kas nepieciešama katram uzdevumam.
• tox-gh-actions: Šis ir noderīgs Tox spraudnis, kas automātiski kartē CI vides Python versiju uz pareizo Tox vidi. Piemēram, uzdevumā, kas darbojas uz Python 3.9, `tox -e py` automātiski tiks izpildīts kā `tox -e py39`. Tas ļauj izvairīties no sarežģītas loģikas rakstīšanas jūsu CI skriptā.

Tagad katru reizi, kad tiek veikts push, jūsu pilna testu matrica tiek automātiski izpildīta visās trijās galvenajās operētājsistēmās. Jūs saņemat tūlītēju atgriezenisko saiti par to, vai izmaiņas nav radījušas nesaderību, ļaujot jums droši veidot saviem globālajiem lietotājiem.

Uzlabotas stratēģijas un labākās prakses

Argumentu nodošana komandām ar {posargs}

Dažreiz jums ir jānosūta papildu argumenti savam testu palaidējam. Piemēram, jūs varētu vēlēties palaist konkrētu testa failu: `pytest tests/test_api.py`. Tox atbalsta to ar ` {posargs} ` aizstāšanu.

Modificējiet savu `tox.ini`:

[testenv]
deps = pytest
commands = pytest {posargs}

Tagad jūs varat izpildīt Tox šādi:

tox -e py310 -- -k "test_login" -v

-- atdala argumentus, kas paredzēti Tox, no argumentiem, kas paredzēti komandai. Viss pēc tā tiks aizstāts ar `{posargs}`. Tox izpildīs: `pytest -k "test_login" -v` `py310` vidē.

Vides mainīgo kontrolēšana

Jūsu lietojumprogramma var atšķirīgi uzvesties atkarībā no vides mainīgajiem (piemēram, `DJANGO_SETTINGS_MODULE`). `setenv` direktīva ļauj jums tos kontrolēt savās Tox vidēs.

[testenv]
setenv =
    PYTHONPATH = .
    MYAPP_MODE = testing

[testenv:docs]
setenv =
    SPHINX_BUILD = 1

Padomi ātrākai Tox izpildei

Palielinoties jūsu matricai, Tox izpilde var kļūt lēna. Šeit ir daži padomi, kā tos paātrināt:

• Paralēlais režīms: Palaidiet `tox -p auto`, lai Tox paralēli palaistu jūsu vides, izmantojot pieejamo CPU kodolu skaitu. Tas ir ļoti efektīvi modernās iekārtās.
• Vide izvēles veidā: Pēc noklusējuma Tox atkārtoti izmanto vides. Ja jūsu atkarības tox.ini vai requirements.txt mainās, jums ir jānorāda Tox, lai vide tiktu izveidota no jauna. Izmantojiet atkārtotas izveides karogu: `tox -r -e py310`.
• CI kešēšana: Savā CI/CD cauruļvadā kešojiet .tox/ direktoriju. Tas var ievērojami paātrināt turpmāko izpildi, jo atkarības nebūs jālejupielādē un jāinstalē katru reizi, ja vien tās nemainās.

Globālas lietošanas gadījumi praksē

Apskatīsim, kā tas attiecas uz dažādiem projektu veidiem globālā kontekstā.

Scenārijs 1: Atvērtā pirmkoda datu analīzes bibliotēka

Jūs uzturat populāru bibliotēku, kas balstīta uz Pandas un NumPy. Jūsu lietotāji ir datu zinātnieki un analītiķi visā pasaulē.

• Izaicinājums: Jums jāatbalsta vairākas Python, Pandas, NumPy versijas un jānodrošina, ka tā darbojas Linux serveros, macOS klēpdatoros un Windows darbstacijās.
• Tox risinājums: envlist = {py39,py310,py311}-{pandas1,pandas2}-{numpy18,numpy19} Jūsu `tox.ini` izmantotu faktora nosacītos iestatījumus, lai katrai videi instalētu pareizās bibliotēku versijas. Jūsu GitHub Actions darba plūsma pārbaudītu šo matricu visās trīs galvenajās operētājsistēmās. Tas nodrošina, ka lietotājs Brazīlijā, kas izmanto vecāku Pandas versiju, saņem tādu pašu uzticamu pieredzi kā lietotājs Japānā ar jaunāko komplektu.

Scenārijs 2: Uzņēmuma SaaS lietojumprogramma ar klientu bibliotēku

Jūsu uzņēmums, kura galvenā mītne atrodas Eiropā, nodrošina SaaS produktu. Jūsu klienti ir lielas, globālas korporācijas, no kurām daudzas izmanto vecākas, ilgtermiņa atbalsta (LTS) versijas operētājsistēmām un Python stabilitātes nolūkos.

• Izaicinājums: Jūsu izstrādes komanda izmanto modernus rīkus, taču jūsu klientu bibliotēkai jābūt savietojamai ar vecākām uzņēmuma vidēm.
• Tox risinājums: envlist = py38, py39, py310, py311 Jūsu `tox.ini` nodrošina, ka visi testi iziet pret Python 3.8, kas varētu būt standarts lielā klientā Ziemeļamerikā. Automātiski izpildot to CI, jūs novēršat izstrādātāju nejaušu funkciju ieviešanu, kas izmanto sintaksi vai bibliotēkas, kas pieejamas tikai jaunākās Python versijās, novēršot dārgas izvietošanas kļūmes.

Secinājums: Izlaidiet ar globālu pārliecību

Testēšana vairākās vidēs vairs nav greznība; tā ir pamata prakse augstas kvalitātes, profesionālas programmatūras izstrādei. Izmantojot automatizāciju ar Tox, jūs pārvēršat šo sarežģīto izaicinājumu par optimizētu, atkārtojamu procesu.

Definējot savas atbalstītās vides vienā `tox.ini` failā un integrējot to ar CI/CD cauruļvadu, jūs izveidojat jaudīgu kvalitātes vārtu. Šie vārti nodrošina, ka jūsu lietojumprogramma ir izturīga, savietojama un gatava daudzveidīgai, globālai auditorijai. Jūs varat pārtraukt uztraukties par bēdīgi slaveno "tas darbojas manā datorā" problēmu un sākt izlaist kodu ar pārliecību, ka tas darbosies ikviena datorā, neatkarīgi no tā, kur viņi atrodas pasaulē.